home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-sdr-pl-00.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
19KB
|
615 lines
SDR Working Group Tony Li
INTERNET DRAFT cisco Systems
6/21/93
Source Demand Routing Policy Language
Status of this Memo
This document defines a policy language for use with the SDRP policy
routing protocol for the Internet. This document specifies an IAB
standards track protocol for the Internet community, and requests
discussion and suggestions for improvements. Please refer to the
current edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol. Distribution of
this document is unlimited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
1 Overview
The purpose of SDRP [1] is to support source-initiated selection of
routes to complement the route selection provided by existing routing
protocols for both inter-domain and intra-domain routes. This
document refers to such source-initiated routes as "SDRP routes".
For the computation of inter-domain routes, it is useful to be able
to remotely request policy information from other routing domains.
This document describes a mechanism and a language for exchanging
policy information. The language provides a common, extensible,
machine interpretable basis for determining if a packet flow is in
compliance with the policies of the remote domain.
Note that in this scheme, only certain transit and destination
policies can be described. This scheme allows a domain to describe
accessibility policies, but does not permit the encoding of route
Expiration Date Dec. 1993 [Page 1]
INTERNET DRAFT June 1993
preferences. Source policies remain private to the originating
domain.
2 Policy requests and replies
Requests for remote policies and replies are sent as SDRP control
messages. Policy requests are sent with a Notification Code of 8,
for "Policy Request", and replies are send with a Notification Code
of 9, for "Policy Reply". The payload of both messages is used to
convey the policy information. For a Policy Request control message,
the payload has the format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Code | Authentication Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For a Policy Reply control message, the payload has the format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Code | Policy Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Policy Information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Code (2 octets) and Authentication Data (variable)
The Authentication Code is a 2 octet unsigned integer that
indicates the authentication mechanism being used. Whenever an
authentication mechanism is specified for use within SDRP,
three things must be included in the specification:
- the value of the Authentication Code that indicates use of
the mechanism,
- the form and meaning of the Authentication Data in Policy
Request messages, and
- the form and meaning of the Authentication Data in Policy
Reply messages.
Expiration Date Dec. 1993 [Page 2]
INTERNET DRAFT June 1993
Only one authentication mechanism is specified as part of this
memo:
- its Authentication Code is zero,
- its Authentication Data field has zero length in both Policy
Request and Policy Reply messages.
The semantics of non-zero Authentication Codes lies outside the
scope of this document.
Policy Length (2 octets)
The Policy Length field is a 2 octet unsigned integer that
indicates the number of octets of policy information that is
contained in a Policy Reply message.
TTL (4 octets)
The TTL field is a four octet unsigned integer. This field is
the time to live of the Policy Reply and indicates the number
of seconds that the Policy Reply may be cached.
Policy Information (variable)
The Policy Information field is a variable length field that
contains the transit and destination policies of the domain
sending the Policy Reply message. The Policy Information is
encoded in the SDRP policy language described below.
3 SDRP Policy Language
The language used for transmission of policy information is a simple,
extensible, easily interpreted form of a boolean expression. A
system that wishes to evaluate a policy for a particular packet or
flow need only substitute appropriate values in the expression. A
result of true indicates that the packet or flow is permissible
within the policy. To aid in debugging and implementation, the
policy language is distributed in ASCII. The additional bandwidth
consumed by not encoding it in binary is expected to be negligible
since policies change infrequently and can be cached for a relatively
long time. The language presented here is loosely based on the
language 'C' [2].
In general, a policy expression is syntactically a 'C' expression,
but no bit manipulations are allowed. An additional "OR" separator
has been added to the language that allows simple separation of
Expiration Date Dec. 1993 [Page 3]
INTERNET DRAFT June 1993
different parts of a policy for independent evaluation.
3.1 Syntax
Spaces, tabs and newlines are ignored except as token separators.
Identifiers are sequences of letters and digits, the first character
must be a letter. Identifiers are case sensitive. The remainder of
the syntax is described in a variant of BNF in which terminals are
enclosed in double quotes. Alternatives for productions are listed
on separate lines.
policy:
expression
policy "OR" expression
expression:
OR-expression
OR-expression "?" expression ":" expression
OR-expression:
AND-expression
OR-expression "||" AND-expression
AND-expression:
equality-expression
AND-expression "&&" equality-expression
equality-expression:
relational-expression
equality-expression "==" relational-expression
equality-expression "!=" relational-expression
relational-expression:
additive-expression
relational-expression "<" additive-expression
relational-expression ">" additive-expression
relational-expression "<=" additive-expression
relational-expression ">=" additive-expression
additive-expression:
multiplicative-expression
additive-expression "+" multiplicative-expression
additive-expression "-" multiplicative-expression
multiplicative-expression:
unary-expression
Expiration Date Dec. 1993 [Page 4]
INTERNET DRAFT June 1993
multiplicative-expression "*" unary-expression
multiplicative-expression "/" unary-expression
multiplicative-expression "%" unary-expression
unary-expression:
primary-expression
unary-operator unary-expression
"(" expression ")"
primary-expression:
identifier
constant
IPaddr
IPaddr:
octet "." octet "." octet "." octet
unary-operator:
"-"
"!"
A constant is a 4 octet unsigned integer. Syntactically, it may be
specified as a string of decimal digits from "0" to "9", or as a
string of hexidecimal digits if preceeded by "0x" or "0X". The
hexidecimal digits are "0" to "9", "a" to "f", and "A" to "F". An
octet is specified as a string of decimal digits from "0" to "9", and
the resulting value must be between 0 and 255.
3.2 Semantics
The semantics for most of this language are taken directly from [2],
which should be considered authoritative for all constructs that are
taken from "||" operator. An IPaddr is semantically equivalent to a
constant.
Thus, evaluation of a policy produces a boolean result, either 0 or
1. Evaluation of the null policy (the empty string) produces the
result 0. A result of 0 indicates that the policy has not been
satisfied and that the this route should not be used. A result of 1
indicates that the route is permissible with respect to this policy.
Expiration Date Dec. 1993 [Page 5]
INTERNET DRAFT June 1993
3.3 Variables
Identifiers that appear in policies are variables that describe some
attribute of the data flow. For each variable used in this language,
there must be a written specification of the variable that includes
the name of the variable and the semantics of the variable.
The value of the variable may be dependent on the traffic in the
flow, external physical constants, or other systems. Any two systems
that support a particular variable must attach identical semantics to
the variable. If a system does not support a variable that occurs in
a policy, the entire expression containing that variable must
evaluate to 0.
3.4 Base variables
This document specifies the following variables:
3.4.1 src_address
The variable "src_address" is the source IP address for packets in
the flow.
3.4.2 dst_address
The variable "dst_address" is the destination IP address for packets
in the flow.
3.4.3 ip_tos
The variable "ip_tos" is the IP Type Of Service octet for packets in
the flow. Note that the value of the entire octet is used [5].
3.4.4 ip_protocol
The variable "ip_protocol" is the Protocol field from the IP header
for packets in the flow.
Expiration Date Dec. 1993 [Page 6]
INTERNET DRAFT June 1993
3.4.5 hour
The variable "hour" is the current hour, in UTC. An implementation
supporting this variable must derive the current time from a reliable
source, such as [2] or [3].
3.4.6 minute
The variable "minute" is the current minute, in UTC. An
implementation supporting this variable must derive the current time
from a reliable source, such as [2] or [3].
3.4.7 day
The variable "day" is the current day of the week for UTC. The
following table lists days and corresponding values. An
implementation supporting this variable must derive the current time
from a reliable source, such as [2] or [3].
Value Day
-------------------
0 Monday
1 Tuesday
2 Wednesday
3 Thursday
4 Friday
5 Saturday
6 Sunday
3.4.8 date
The variable "date" is the current day of the month for UTC. Legal
values are 1 through 31. An implementation supporting this variable
must derive the current time from a reliable source, such as [2] or
[3].
3.4.9 month
The variable "month" is the current month for UTC. The following
Expiration Date Dec. 1993 [Page 7]
INTERNET DRAFT June 1993
table lists months and their corresponding values. An implementation
supporting this variable must derive the current time from a reliable
source, such as [2] or [3].
Value Month
-------------------
1 January
2 February
3 March
4 April
5 May
6 June
7 July
8 August
9 September
10 October
11 November
12 December
3.4.10 year
The variable "year" is the current year for UTC. Legal values are
integers greater than or equal to 1993. An implementation supporting
this variable must derive the current time from a reliable source,
such as [2] or [3].
3.4.11 src_port
The variable "src_port" is the source port for TCP or UDP packets for
packets in the flow.
3.4.12 dst_port
The variable "dst_port" is the destination port for TCP or UDP
packets for packets in the flow.
3.4.13 new_connection
The variable "new_connection" has value 0 for TCP packets that have
the ACK or RST bit set and the value 1 otherwise. A frequent
Expiration Date Dec. 1993 [Page 8]
INTERNET DRAFT June 1993
application is deny new connections to particular ports in the
destination domain.
3.5 Future research
We would also like to be able to create variables that represent the
domain of the source and the domain of the destination. However no
standard mechanism exists for determining this information
dynamically.
We would also like to be able to classify the community associated
with a particular traffic flow, such as Research, Education,
Commercial, or Government.
There has also been some discussion about performing pattern matching
on the entire SDRP route. The utility of this is not yet clear and
is a matter for future research. This may require adding pattern
matching primitives to the language.
A frequent request is the ability to determine the utilization of
inter-domain links. There is currently no standard mechanism for
relaying this information. Note that if such a mechanism is
developed, it should be independent of this policy language, possibly
as another component to SDRP.
4 Examples
This section demonstrates how this policy language might be used.
Suppose that a company `SANFRAN' has many interconnections to a
number of different networks.
Suppose that SANFRAN agrees that a local eductional institution may
use its domain as a transit. The educational institution uses
network address 63.0.0.0, and all packets destined or sourced from
this network would be permitted:
(src_address > 63.0.0.0) && (src_address < 63.255.255.255) ||
(dest_address >= 63.0.0.0) && (dst_address <= 63.255.255.255)
SANFRAN then decides that this is too restrictive and it also wishes
to provide transit service for DNS. DNS uses port 53 over both TCP
(protocol 6) and UDP (protocol 17):
(src_address > 63.0.0.0) && (src_address < 63.255.255.255) ||
Expiration Date Dec. 1993 [Page 9]
INTERNET DRAFT June 1993
(dest_address >= 63.0.0.0) && (dst_address <= 63.255.255.255)
OR
((src_port == 53) || (dst_port == 53) &&
(ip_protocol == 6) || (ip_protocol == 17))
SANFRAN also wishes to allow all Research networks to use it as a
transit. To do this, it makes use of a new variable called
"community", for which the Research community has the value 4:
...
OR
community == 4
This policy will be ignored by any SDRP speaker which does not
support that variable.
SANFRAN also is willing to provide transit service after business
hours, on weekends and on Groundhog day. This policy allows traffic
between the hours of 1100UTC and 1900UTC, on Saturday and Sunday, and
on Feb. 2nd:
...
OR
(hour >= 1100) && (hour <= 1900) ||
(day == 5) || (day == 6) ||
(month == 2) && (date == 2)
5 Security Considerations
Security issues are not discussed in this memo.
6 Acknowledgements
The author would like to express his thanks to Deborah Estrin
(USC/ISI), Steve Hotz (USC/ISI), and Yakov Rekhter (IBM) for their
insightful comments and assistance.
7 Author's Address
Tony Li
cisco Systems, Inc.
1525 O'Brien Drive
Menlo Park, CA 94025
Expiration Date Dec. 1993 [Page 10]
INTERNET DRAFT June 1993
Phone: (415) 688-8186
email: tli@cisco.com
8 References
[1] Estrin, D., Li, T., Rekhter, Y., "Source Demand Routing: Packet Format
and Forwarding Specification (Version 1)", work in progress
[2] Kernighan, B.W., Ritchie, D.M., "The C Programming Language", Second
Edition, Prentice-Hall, New Jersey, 1998
[3] Mills, D.L., "Simple Network Time Protocol (SNTP)", RFC 1361, August
1992
[4] Mills, D.L., "Network Time Protocol (Version 3): Specification,
implementation, and analysis", RFC 1305, March 1992
[5] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC
1349, July 1992
Expiration Date Dec. 1993 [Page 11]